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10 La presents invention concerne un proc^de de mise a jour d'applications pour 
carte a puce. 



15 



20 



25 



une 



30 



Elle a plus particulierement pour objet de permettre le chargement d' 
nouvelle version d'une application dans une carte a puce tout en conservant les 
donnees utilisees pai- les precedentes versions de I'application. il- 

■ -uSi. ' - 

La plupart des systemes de cartes a puce actuelles utilisent des machini. 
virtuelles, la plus populaire d'entre elle etant celle de « Java Card » (marqiS ' 
d^pos^e par la Societe Sun Microsystems). Dans ce systeme, les donnees 
persistantes des applications sont stockees comme des objets, et en particulier 
comme des instances des classes defmies dans les programmes charges dans la 
carte. La nature persistants de ces objets rend done les programmes actifs en 
pen^anence dans la carte, ^ I'inverse de ce qui se produit dans les systemes 
classiques (stations de travail, ordinateurs de bureau). Cela pose un probleme 
particulier pour la mise a jour des programmes, puisqu'il n'est pas possible de 
profiter d'un moment ou le programme n'est pas actif pour le raettre a jour. 

De plus, la plupart des plates-formes utilisent un format de code binaire 
optimise (format dit «CAP File» dans le cas de « Java Card »). Ce format 
permet de ne charger sur une carte que les infomaations sti-ictement 
necessaires a I'execution du programme. En particulier, il ne contient pas 
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toujours les infonnations necessaires pour effectuer une mise a jour de 

r application. 

Enfin, une carte a puce est un contexte d'execution tres particulier, dans la 
5 mesure ou elle est difiusee en de tres nombreux exemplaires, et elle contient 
souvent des informations confidentielles. En particulier, il est tres difficile 
d'envisager de mettre a jour une application en effa9ant Tappiication existante 
et ses donnees, en rechargeant la nouvelle application, puis en rechargeant les 
donnees. En effet^ les donnees d'initialisation des applications sont 
10 general ement tres sensibles, et ne doivent absolument pas Stre manipulees en 
dehors des sites de production des cartes, sous des conditions de securite tres 
controlees. 



La nature des problemes rencontres depend fortement des caracteristiques de 
15 la mise a jour souhaitee. Pour la mise a jour d'une application, les problemes 
sont les suivants : 

® Mise a jour de code simple. 

Le probleme est ici de corriger des defauts du programme, sans en modifier 
20 la structure. II s'agit done simplenient de modifier la definition de certaines 
methodes, et eventuellement de raj outer de nouvelles methodes, voire de 
nouvelles classes (en dehors de la hierarchie existante). 

^ Mise a jour de code avec modification de la hierarchie de classes. 
25 Le probleme est ici de corriger des defauts structurels du programme, 
necessitant une modification de la hierarchie de classes (habituellement par 
insertion d'une classe au milieu d'une hierarchie existante pour prendre en 
compte un comportement specifique). 
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15 



20 



® Mise a jour avec modification de la structure de I'objet. 

Le probleme est ici de corriger un defaut n6cessitant le stockage 
d'informations supplementaires, et done I'ajout de champs de donn^es dans 
des classes existantes. Ce probleme est plus complexe dans la mesure ou las 
objets existants doivent atre modifies pour prendre en compte les 
modifications. 

Dans certains cas, I'application k mettre a jour est accessible depuis d'autres 
applications, en paiticulier quand I'application exporte des interfaces 
partageabies et quand I'application est en fait une librairie. D'un point de vue 
purement technique, de telles mises a jour posent les memes problemes que les 
mises a jour simples d'applications, a la difference pres que les mises k jour 
doivent etre appliquees a toutes les applications qui importent les fonctions 
modifi^es. 

L'invention a done plus particulierement pour but la realisation d'un- 
mecanisme de chargement d'une nouvelle version d'une application, qui! 
remplace une application deja presente sur une carte avec des garanties en " 
matiere de securite et de continuite de fonctionnement, ce mecanisme" 
permettant done de modifier des applications sans inteiTompre leur 
fonctionnement. 



Elle se propose d'aboutir a ce resultat en utilisant une option specifique de 
commande de chargement et un format de chargement compatible avec celui 
25 defmi dans la specification « Java Card ». 

En vue de parvenir a ces resultats, elle propose, d'une fa9on generale, un 
precede pour le chargement sur un dispositif informatique d'une nouvelle 
version d'une application dans un langage de programmation a objets et 
30 permettant, notamment, I'introduction de classes supplementaires, la 
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modification de la hierarchic de classes et la definition de champs et de 
methodes supplementaires. 

Selon rinvention, ce precede consiste a : 

" calculer prealablement a ce chargement une information permettant d'etablir 
la con-espondance entre les classes de Tancienne version de Tapplication et 
les classes de la nouvelle version de Tapplication ; 

- calculer prealablement a ce chargement une infonnation permettant d'etablir 
la correspondance entre les identificateurs des champs statiques de 
Tancienne version de I'application des identificateurs des champs statiques 
de la nouvelle version de I'application ; 

- associer lesdites infomiations de correspondance a la nouvelle version de 
Tapplication chargee sur le dispositif ; 

- utiliser lesdites informations de correspondance pour modifier les objets de 
fa9on a ce qu41s pointent vers les classes de la nouvelle version de 
Tapplication et qu'ils utilisent les nouveaux identificateurs des champs 
statiques de la nouvelle version de rappHcation. 

Avantageusement, lesdites informations de correspondance pourront consister 
en des tables de correspondance. 

Elles pourront gtre omises dans le cas ou les modifications des objets ne sont 
pas necessaires, par exemple, et de fa9on non limitative, quand aucune classe 
suppleraentaire n'est ajoutee dans la nouvelle version de Tapplication ou quand 
les classes ajoutees ne modifient pas la hierarchic de classes, 

Le procede selon Tinvention pourra comprendre Texecution de methodes de 
mise a jour des donnees de Tapplication apres installation de la nouvelle 
version de Tapplication. 
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Un mode d'execution de I'invention sera decrit ci-apres, a titre d'exemple non 
limitatif, avec reference aux dessins annexes dans lesquels : 

Les figures la et lb sont des tableaux comparatifs montrant la 
hierarchic de classes de I'application, dans sa version originate (figure 
la) et dans sa nouvelle version (figure lb) ; 

La figure 2 est une table de correspondaiice donnant, pour chaque 
classe de I'application originale, I'index de la classe correspondante 
dans la nouvelle application ; 

Les figures 3a et 3b sont des tableaux comparatifs montrant une 
hierarchic avec la propriete recherchee, hierarchic originale (figure 3a) 
et nouvelle hierarchic (figure 3b) ; -L 

' ■ % 

La figure 4 est une table de correspondance entre des tables d& 
correspondance (table originale/nouvelJe table) correspondant a \f0 
hitechie illustree figure 3 b ; 

La figure 5 est une table de correspondance du type de celle de la figure 
4 pour les champs statiques ; 

Les figures 6 a 8 sont des representations schematiques illustrant les 
etats d'une carte a puce, avant mise a jour (figure 6), apres chargement 
de la nouvelle application (figure 7) et aprds modification des objets 
(figure 8). 

La mise en oeuvre de i'invention se fait en plusieurs etapes : 

* Preparation du fichier de chargement. 

• Chargement du fichier et edition de liens. 
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o Mise 6 jour des objets de I'application, 

o Execution d'une methode sp6cifique de mise a jour. 

Le fichier de chargement doit contenir des informations specifiques qui 
permettent d'^tablir la correspondance avec une ou plusieurs versions 
anterieures de I'application. Afin de generer le fichier de mise a jour, ii est 
necessaire de disposer des objets suivants : 

9 Tous les fichiers de classe de I'application originate. 

® Le fichier de chargement (« CAP File » dans le cas de « Java Card ») de 

I'application originale. 
® Tous les fichiers de classe de la nouvelle version de I'application. 
® Tous les fichiers d'export requis pour construire la nouvelle version de 

I'application. 

Si le fichier de chargement de I'application originale comprend des 
informations de typage et de nommage des classes, il n'est alors pas 
indispensable de disposer des fichiers de classe de I'application originale. 

Les donnees d'entrees doivent respecter les conti-aintes suivantes : 

® Pour chaque element de Tapplication originale, il existe dans la nouvelle 
version de I'application un element equivalent (de meme nom et de m6me 
type). 

9 Si I'application originale exporte une interface exteme aux autres 
applications, cette interface externe doit etre inchangee dans la nouvelle 
version de I'application. 

® Les fichiers d'export utilises dans la nouvelle version de I'applications sont 
binaires-compatibles (c'est-a-dire qu'ils peuvent Stre relies sans 
modification aux autres parties de I'application initiale) avec ceux utilises 
dans I'application originale. Dans le cas de « Java Card », il s'agit de ceux 
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qui sont Ustes dans le composant d'import du fichier de cliargement 
original. 

Le fichier de chargement genere est un fichier de chargement normal, qui peut 
5 done etre charge sur n'iraporte quelle carte. Ce fichier contient un composant 
optionnel avec les informations suivantes pour chaque version precedente de 
Tapplication prise en consideration : 

- le numero de cette version, 

10 - une table qui etablit une correspondance entre chaque classe ou interface 
defmie dans Tancienne version et la nouvelle version de cette classe ou 
interface dans la nouvelle version de Tapplication, 

- une table qui etablit une correspondance entre I'identifiant de chaque champ 
statique de Tancienne version et le nouvel identifiant de ce champ dans la ,, 

15 nouvelle version, 

Ces informations supplementaires ne sont necessaires que pour les operations ^i- 
de raise a jour, Le meme fichier binaire peut done servir pour ie chargementi.;;- 
de Tapplication et pour la mise a jour d'applications. 

20 

Dans un premier exemple, les hierarchies de classe de I'application dans sa 
version originale et dans sa nouvelle version sont montr^es sur les figures la 
et lb. La hierarchic originale comporte quatre classes (Classe A a Classe D) et 
la nouvelle hierarchic comporte quatre classes supplementaires (Classe E, 
25 Classe F, Classe A2, Classe C2) dont certaines (Classe A2 et Classe C2) sont 
inserees dans la hierarchic originale. 

Dans ce cas, luie table de correspondance peut Stre 6tablie. 
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Comme illustre figure 2, cette table de con-espondance peut, par exemple, 
donner, pour chaque classe de I'application originale, I'index II, 13, 14, 16 de la 
classe correspondante dans la nouvelle application. 

5 L'exemple suivant conceme un cas particulier dans lequel la table 
suppl6mentaire n'a pas besoin d'etre incluse dans le fichier de chargement. 
Ceci est possible si : 

® La hierarchic des classes de I'application originale est conserv^e inchang6e 
0 dans la nouvelle version de I'application (aucune classe n'est inseree dans la 
hierarchic). 

® Les classes de I'application originale sont definies en premier dans le 
nouveau ficher de chargement, et dans le m&ne ordre que dans le fichier de 
5 chargement original. 

Les figures 3a et 3b montrent une hierarchic avec la propriete recherchee dans 
laquelle la nouvelle hierarchic (figure 3b) inclut les classes E et F sans 
insertion dans la hierarchie originale (figure 3a) des classes A a D. 

La figure 4 montre les tables de classes correspondant a cette hierarchic, et 
respectant la propriete d'ordre indiquee ci-dessus. On voit alors que la table de 
correspondance est triviale et n'est pas necessaire. 

Le fichier doit egalement contenir une table de correspondance entre les 
champs statiques de I'application originale et ceux de la nouvelle version de 
I'application. Cette table est similaire k la pr6cedente, mais elle est cette fois 
indexee par les identifiants des nouveaux champs statiques ; les elements de la 
table qui coirespondent a des nouveaux champs contiennent un identifiant 
invalide (10 dans l'exemple), et les autres elements contiennent I'identifiant du 
meme champ dans la version originale. 
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La figure 5 montre un example d'une telle table comprenant : 

- une table originale comportant les champs A.champl, A.champ2, 
5 C.champl, A.champ3, 

- une nouvelle table comportant les champs A.champ2, A.champl, 
C.champl, C.champ2, A.champS, F.champl, 

10 - une table de correspondance dans laquelle le champ A.champl est index^ 
par I'identifiant II, A.champ2 est index6 par I'identifiant 12, C.champl est 

indexe par I'identifiant 13, A.champS est indexe par I'identifiant 14 ; les 
nouveaux champs C.champ2 et F.champl contiennent un identifiant 
invalide = 10. 

15 

Une fois le fichier approprie genere, il faut le charger dans la carte. On peut 
supposer que I'etat de la carte avant chargement est comme indique en figure ^f. 
avec un objet Objl en ClasseA et un objet Obj2 en ClasseB de I'applicatioii;.; 
Appl. > 

20 

Le chargement s'effectue en utilisant la procedure d'edition de liens normale 
du systeme. 

La figure 7 montre I'etat de la carte apres le chargement de la nouvelle 
25 application. La nouvelle version de I'application Appl' est chargee, mais les 
objets Objl, Obj2 de rapplication pointent toujours vers I'ancienne version 
(ClasseA, ClasseB de I'application Appl). 

Une des phases du chargement est I'initialisation des champs statiques. La 
30 procedure standard d'initialisation est appliqu6e, sauf pour les champs qui sont 
herites de I'application originale. Pour ces champs, la valeur initiale definie 
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dans la nouvelle version de I'application est ignoree, et I'ancienne valeur est 
copiee. 

L'6tape suivajite consiste done a modifier les liens des objets pour qu'ils 
5 pointent vers les nouvelles classes. II faut alors parcourir tous les objets de 
I'application et utiliser la table de correspondance entre anciennes et nouvelles 
classes pour identifier la nouvelle classe de I'objet. 

Le resultat est montre figure 8, ou les objets Objl, Obj2 pointent sur les 
10 nouvelles classes (ClasseA*, ClasseB'). 

Lors de cette etape, il se peut que les objets doivent etre modifies, si de 
nouveaux champs ont ete ajoutes a leur classe. Dans ce cas, un nouvel objet ' 
(avec les nouveaux champs) est alloue, les valeurs des anciens champs sont 
copiees de i'ancienne version de I'objet, et les valeurs des nouveaux champs 
sont initialisees a leur valeur par defaut (0 pour les entiers, "false" pour les 
booleens, et "null" pour les pointeurs). Les references vers I'ancien objet sont 
ensuite mises a jour en utilisant des techniques classiquement implementees 
dans les recuperateurs de memoire. 



15 



20 



25 



La derniere etape consiste a laisser I'application faire toutes les operations 
n^cessaires a la mise a jour des donnees et, en particulier, de proceder a 
initialisation des nouveaux champs (champs statiques, ou champs inseres 
dans des objets). Les applets qui ont besoin d'effectuer une mise a jour doivent 
implementer une interface specifique, dans laquelle une m6thode est defmie. 
La mise a jour consiste done a parcourir la table des applets enregistr6es dans 
le systeme et, pour chaque applet qui est une instance d'une classe definie dans 
le package mis a jour et qu'implemente I'interface de mise a jour, d'invoquer la 
methode avec les parametres appropries. 
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Revendications 

1 . Procede pour ie chai'gement sur un dispositif informatique d'une 
nouvelle version d'une application dans un langage de programmation a objets 
et permettant, notamment, Tintroduction de classes suppleraentaires, la 
modification de la hierarchic de classes et la definition de champs et de 
methodes supplementaires, 

caracterise en ce qu'il consiste a : 

- calculer prealablement a ce chargement une information permettant d'etablir 
la correspondance entre les classes de Fancienne version de I'application et 
les classes de la nouvelle version de Tapplication ; 

- calculer prealablement a ce chargement une information permettant d'etablir 
la correspondance entre les identificateurs des champs statiques de 
Tancienne version de Tapplication des identificateurs des champs statiques 

. de la nouvelle version de Tapplication ; • , - 

- associer lesdites informations de correspondance k la nouvelle version de 
Fapplication chargee sur le dispositif ; 

- utiliser lesdites informations de correspondance pour modifier les objets de 
fa9on a ce qu'ils pointent vers les classes de la nouvelle version de 
Tapplication et qu'ils utilisent les nouveaux identificateurs des champs 
statiques de la nouvelle version de Tapplication. 

2. Procede selon la revendication 1, 

caracterise en ce que lesdites informations de correspondance sont des tables 
de correspondance. 

3. Procede selon Tune des revendications 1 et 2, 

caracterise. en ce que lesdites informations de correspondance sont omises 
dans le cas ou les modifications des objets ne sont pas n^cessaires quand 
aucune classe supplementaire n*est ajoutee dans la nouvelle version de 
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I'application ou quand les classes ajoutees ne modifient pas la hierarchie de 
classes. 



4. Procede selon Tune des revendications precedentes, 
caracterise en ce qu'il comprend I'execution de raethodes de mise a jour des 
donnees de I'application apres I'installation de la nouveile version de 
I'application. 



5. Procede selon Tune des revendications precedentes, 
caracterise en ce que ledit dispositif informatique est une carte 4 puce. 

6. Procede selon Tune des revendications precedentes, 

caracterise en ce que ledit langage de programmation est le langage « Java 
Card ». 



~~7 
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